This paper is an example of interfaces that allow live coding during a performance. The author notes that programming while performing is a dangerous activity that often results in catastrophic failures. He notes that one way around this is to preview changes before transitioning into new code by having two duplicate systems running side by sides as in DJ setups.

The advantage of coding on the fly during performance is that it is very improvisational:

" These live coding performanceshave a great improvisatory potential and

can adapt to the night and venue, as well as great dangers. They are hardly the best way of solving the laptop-performer-stuck-behind-the-laptop dilemma, nor of minimizing crashes. Yet they are of sufficient interest to warrant further attention, and whilst not all

performers would ever wish to tackle a constant set of text entry, one can use the techniques in integration with spawned user interfaces, with external controllers or other more conventional audio programs."

Even so, it seems that the author's reasons for coding live are more based in the challenge of the form and the thrill of pulling something off that is hard to accomplish. However, it does point out the need for a compositional element that allows for flexibility for the very technically minded to structure and create experiences using mechanisms of their own devising. What is interesting is that a mechanism can be created that contains this wild form and provides ways to tame it in the context of other events within a performance.

For instance a cuing system or timeline could transition the audio from a default stream to the coded stream or between coded streams. This should be an already available programmed capability not something the user has to engineer. By doing this, the user is saved from having to do work that has already been done over and over by other artists.